The present invention relates to the field of computer science. More particularly, the present invention relates to a method for Meta Object Facility (MOF) repository bootstrap.
Today""s Internet-driven economy has accelerated users"" expectations for unfettered access to information resources and transparent data exchange among applications. One of the key issues limiting data interoperability today is that of incompatible metadata. Metadata is information about other data, or simply data about data. Metadata is typically used by tools, databases, applications and other information processes to define the structure and meaning of data objects.
Unfortunately, most applications are designed with proprietary schemes for modeling metadata. Applications that define data using different semantics, structures and syntax are difficult to integrate, impeding the free flow of information access across application boundaries. This lack of metadata interoperability hampers the development and efficient deployment of numerous business solutions. These solutions include data warehousing, business intelligence, business-to-business exchanges, enterprise information portals and software development.
An improvement is made possible by establishing standards based upon XML Document Type Definitions (DTDs). However, DTDs lack the capability to represent complex, semantically rich, hierarchical metadata.
A further improvement is made possible by the Meta Object Facility (MOF) specification. MOF is described in a text entitled xe2x80x9cMeta Object Facility (MOF) Specificationxe2x80x9d, Object Management Group, Inc., version 1.3, March 2000. The MOF specification defines a standard for metadata management. The goal of MOF is to provide a framework and services to enable model and metadata driven systems. The MOF is a layered metadata architecture consisting of a single meta-metamodel (M3), metamodels (M2) and models (M1) of information. Each meta level is an abstraction of the meta level below it. These levels of abstraction are relative, and provide a visual reference of MOF based frameworks. Metamodeling is typically described using a four-layer architecture. These layers represent different levels of data and metadata. Layers M1, M2 and M3 are depicted in FIG. 1A. FIG. 1B includes a summary and example of each layer.
The information layer (also known as the M0 or data layer) refers to actual instances of information. These are not shown in FIG. 1A, but examples of this layer include instances of a particular database, application data objects, etc.
The model layer 100 (also known as the M1 or metadata layer) defines the information layer. The model layer 100 describes the format and semantics of the data. The metadata specifies, for example, a table definition in a database schema that describes the format of the M0 level instances. A complete database schema combines many metadata definitions to construct a database model. The M1 layer 100 represents instances (or realizations) of one or more metamodels.
The metamodel layer 105 (also known as the M2 or meta-metadata layer) defines the model layer. The metamodel layer 105 describes the structure and semantics of the metadata. The metamodel specifies, for example, a database system table that describes the format of a table definition. A metamodel can also be thought of as a modeling language for describing different kinds of data. The M2 layer represents abstractions of software systems modeled using the MOF Model. Typically, metamodels describe technologies such as relational databases, vertical domains, etc.
The meta-metamodel (M3) layer 110 defines the metamodel layer. The meta-metamodel layer 110 describes the structure and semantics of the meta-metadata. It is the common xe2x80x9clanguagexe2x80x9d that describes all other models of information. Typically, the meta-metamodel is defined by the system that supports the metamodeling environment. In the case of relational databases, the meta-metamodel is hard-wired by the SQL standard.
In addition to the information-modeling infrastructure, the MOF specification defines an Interface Definition Language (IDL) mapping for manipulating metadata. More specifically, for any given MOF compliant metamodel, the IDL mapping generates a set of Application Program Interfaces (APIs) that provide a common IDL programming model for manipulating the information contained in any instance of that metamodel. The MOF model itself is a MOF compliant model. Therefore, the MOF model can be described using the MOF. Consequently, APIs used to manipulate instances of the MOF Model (i.e., metamodels) conform to the MOF to IDL mapping.
Other mappings may be used to manipulate metadata. The mappings define how to generate a set of APIs that provide a common programming model for manipulating metadata of any MOF compliant model. Using the mappings, applications and tools that specify their interfaces to the models using MOF-compliant Unified Modeling Language (UML) can have the interfaces to the models automatically generated. Using this generated set of APIs, applications can access (create, delete, update and retrieve) information contained in a MOF compliant model.
The MOF also defines a set of reflexive APIs. Similar to Java(trademark) reflection, MOF reflection provides introspection for manipulating complex information. The MOF reflexive interfaces allow a program to discover and manipulate information without using the tailored APIs rendered using the MOF to IDL mapping (or the mapping of MOF to another programming language).
Metamodel and metadata interchange via XML is enabled by XML Metadata Interchange (XMI) specification, an XML-based mechanism for interchanging metamodel information among applications. The XML Metadata Interchange (XMI) standard provides a mapping from MOF to XML. That is, information that has been modeled in MOF can be rendered in XML DTDs and XML documents using the XMI mapping.
Object repositories typically include methods for adding, updating and reading object information maintained in the repository. A MOF repository is more flexible. Initially, a MOF repository includes methods for manipulating MOF objects. An implementor of a MOF repository typically hard-codes the implementation of these methods. Once this is done, a user may create MOF objects and the MOF repository can create methods to manipulate objects of the metamodel that is described by the MOF objects. However, a change to the model of MOF typically requires reimplementing the methods for manipulating MOF objects. This is described in more detail below with reference to FIG. 2.
Turning now to FIG. 2, a typical method for implementing a MOF repository is illustrated. At 200, the developer of a MOF repository hard-codes the implementation of methods for accessing MOF objects. This is required in order for users to create metamodels. At 205, the repository user creates objects describing or modeling a language. At 210, the repository user indicates that the classes added at reference numeral 205 describe a particular metamodel. At 215, the metamodel is instantiated, creating a new xe2x80x9crepository contextxe2x80x9d or instance of the metamodel. Instantiating a metamodel creates helper objects or proxies for each package, association and class in the model. These proxies may be used to create instances of metamodel elements until the model of MOF changes.
At some point, a new version of the MOF model is promulgated. At 220, a determination is made regarding whether the model of MOF has changed. When the model of MOF changes, a repository developer may continue using the old MOF version or the repository developer may decide to use the new MOF version. If the repository developer decides to use the new MOF version, at 225, the repository implementation must be rewritten to comply with the new MOF version.
Reimplementing an entire MOF repository when the model of MOF changes requires significant coding efforts. What is needed is a solution that reduces the amount of coding required when the model of MOF changes.
A method for loading a model of Meta Object Facility (MOF) includes creating a first MOF instance including a model of MOF that is based upon a stored definition of MOF, rebuilding the first MOF instance to make it a metamodel of itself, instantiating the first MOF instance to create a second MOF instance, loading the stored definition of MOF into the second MOF instance and rebuilding the second MOF instance to make the second MOF instance a metamodel of the second MOF instance. An apparatus for loading a model of Meta Object Facility (MOF) includes a boot loader to create a first MOF instance including a model of MOF that is based upon a stored definition of MOF, a rebuilder to rebuild a MOF instance to make it a metamodel of itself, an instantiator to instantiate the first MOF instance to create a second MOF instance and a loader to load the stored definition of MOF into the second MOF instance. The instantiator is further configured to dynamically implement interfaces.